MuleSoft Direct for Data Cloud

This guide provides some additional information with regards to the configuration and setup of various components involved in this use case.

Overview

• Salesforce Connected App creation
• Connecting Salesforce and MuleSoft
• Finding credentials for deployments
• Validating application connectivity
• Interacting with the ingestion APIs
• Enable diagnostic logging
• MuleSoft Direct common configuration issues

See also

• Common Setup Errors

Salesforce Connected App creation

To create a Salesforce connected app for integration applications, follow the steps outlined in the Create a MuleSoft Direct Connected App section on the Set Up the MuleSoft Direct Connector page.

Important: include only the scopes listed. In particular, if the connected app has been granted the Full Access (full) scope, the token exchange will succeed but Data Cloud may not provide the Tenant Endpoint value required to invoke the ingestion API in the response. This may cause an invalid auth token to be cached, which must manually be deleted from the Object Store before attempting to authenticate again after the offending scope has been removed from the connected app.

Connecting Salesforce and MuleSoft

To establish the Anypoint connection in MuleSoft Direct, refer to the instructions on the Connect Your Salesforce and MuleSoft Instances page. If selecting the User Credentials option, ensure the user has organization administrator permissions at the root org level in order to establish a successful connection. If using the Connected App option, some of the scopes listed on the Scopes to Add When You Create a Connected App page refer to the root org, while others refer to the target deployment org. In particular, the following scopes must be granted at the root org level:

• create:client_applications
• manage:org_client_applications
• read:client_applications
• read:exchange
• read:organization

Note: If permissions are granted to only a single environment in the target org, and that org has multiple environments, some additional permissions may be required. If the attempt to connect continues to fail, even with all the documented scopes applied, try adding the following at the org level(s) indicated:

• manage:api_contracts (root)
• manage:api_policies (root and target)
• manage:client_application (root and target)
• read:orgclientproviders (root)
• view:envclientproviders (target)

Finding credentials for deployments

Applications deployed by MuleSoft Direct are protected by a Managed API policy that requires client credentials be provided as a Basic Auth header. These credentials can be found in the Client Application registered for a specific managed API instance, the ID of which is referenced by the runtime property api.autodiscoveryID configured for the application. Here is a summary of how these components are linked back to objects in Salesforce when MuleSoft Direct enables an instance of the application:

• An API specification unique to the deployment is generated in Exchange
• A Managed API is created from that specification
• A Client Application with the credentials to invoke the Managed API is registered against it (one client app is created per Salesforce org)
• The Managed API ID is referenced in the api.autodiscoveryID property of the deployed application
• In Salesforce, the app is referenced from a Named Credential with the same client ID as the Client Application
• The Named Credential is listed on the MuleSoft Direct page for an enabled app

Once you have the client ID and secret for a deployment, you can use these values in the Postman collection provided with the integration templates to directly invoke the APIs - more on this below. Note that you can also look up the associated client application by Salesforce org ID.

Validating application connectivity

The integration applications generally require two separate connections to external systems: one to Data Cloud and one to the source system the application has been configured for (such as Google Drive). To assist in troubleshooting connection issues, each application includes a health check endpoint exposed as /api/ping. When invoked with no parameters it will return the status of the application itself. When the query parameter checkDependencies=true is added, it will also test authenticated connectivity to the external systems and include the results in the response.

For example, making a GET request to the https://{{host-name}}/api/ping?checkDependencies=true endpoint of a Salesforce Data Cloud Ingestion from SharePoint Process API deployment would return something like the following:

{
    "status": "OK",
    "apiName": "ingest-sharepoint-prc-api",
    "apiVersion": "1.0.10",
    "dependencies": [
        {
            "name": "DataCloud",
            "status": "UP"
        },
        {
            "name": "SharePoint",
            "status": "UP"
        }
    ]
}

Sample health check requests can be found in the Postman collection included with each integration template.

Interacting with the ingestion APIs

As mentioned above, each integration template provides a Postman collection, which can be used to interact with the deployed APIs outside of Data Cloud. Each collection provides (at a minimum) a set of requests to interact with each of the endpoints defined by the Salesforce Data Cloud Ingestion Process API specification. Here is a basic summary of the endpoints implemented by each application and how invoking them directly can be useful for testing and troubleshooting efforts.

In order to invoke any of these requests you will need to supply appropriate values to a number of collection variables, including the target hostname and the client ID and secret of the managed API (see above).

Enable diagnostic logging

When troubleshooting application deployments it is often helpful to enable enhanced logging to get more information reported in Runtime Manager. From the main application settings page in Runtime Manager, select the Logging tab for CloudHub deployments or Monitoring tab for CloudHub 2.0 deployments. Add the following log levels and categories:

Click Apply Changes to have the updated logging levels take effect.

MuleSoft Direct common configuration issues

The following table describes some common configuration issues that may arise when attempting to enable integrations from MuleSoft Direct and the potential solutions to them.